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PROCEDE ET DISPOSITIF D'ANALYSE DE LA SECURITE D'UN SYSTEME 



D'INFORMATION 



La presente invention se rapporte au domaine des outils d'analyse et 
de maitrise de la security des systemes d'information (SSI). 

Les outils de conception structure d'un systeme d'information (tels 
que SADT ou SART) ne prennent pas en compte la s6curite du systeme. Les 

5 methodes g6n6ralistes d'analyse du risque (telles que Marion, Melisa, ou 
CRAMM) sont peu ptecises, et incapables de mettre en evidence les failles 
techniques d'un systeme. Les outils de surete de fonctionnement (SDF) sont 
limites aux problemes de fiabilite et de disponibilite, mais ne prennent pas en 
compte la malveillance. Les systemes de detection d'intrusion (IDS pour 

10 "Intrusion Detection Systems") et les analyseurs de vulnerabilite ne 
fonctionnent que sur des systemes reels, sont spgcifiques d'un domaine 
restreint, et n'ont qu'une vision partielle de la securite. Les 6diteurs de strategie 
de securite fonctionnent selon le point de vue du defenseur seulement, et ne 
comportent pas de fonction d'analyse de la coherence de la securite, n» de 

1 5 recherche des failles et des attaques possibles. 

L'invention a pour objet un precede et un dispositif d'analyse de la 
securite des systemes d'information qui repose sur la modelisation et la 
simulation du systeme et des attaques possibles, pour analyser et maTtriser la 
securite du systeme. 

20 Plus particulierement, un premier aspect de l'invention concerne un 

procede d'analyse de la securite d'un systeme d'information comprenant : 

- une phase de modelisation comprenant la mod6lisation du systeme 
d'information ; et, 

- une phase de simulation, comprenant la specification et la simulation 
25 d'attaques potentielles contre le systeme d'information. 

La phase de modelisation comprend la specification de Parchitecture 
du systeme avec un ensemble de composants du systeme et des relations 
entre lesdits composants, c'est-a-dire suivant un modele 
composants / relations. 

30 De preference, des etats determines sont assoctes a chaque 

composant du systeme d'information, chaque etat pouvant prendre une valeur 



WO 2004/046974 




CT/FR2003/003309 



2 



saine et une ou plusieurs valeurs non saines. Certains au moins desdits 6tats 
se rapportent respectivement & I'activite, a la confidentialite, a Hntegrite et/ou a 
la disponibilite du cornposant auquel ils sont associes. 

De preference, la phase de modelisation comprend en outre la 
5 specification d'un ensemble de regies de comportement, notamment au plan 

du fonctionnement du systeme et au plan de la securite (regies de protection), 

associees aux composants du systeme. 

Selon un avantage de I'invention, I'utilisateur peut adopter le point de 

vue du defenseur pendant la phase de modelisation, et le point de vue de 
10 Pattaquant pendant la phase de simulation. En iterant des phases de 

modelisation et des phases de simulation alternees, il parvient a mattriser la 

securite du systeme d'information. 

Selon un autre avantage, I'invention permet d'analyser la securite d'un 

systeme d'information sans intervention directe sur celui-ci. En effet, le 
15 lancement des attaques se fait sur un systeme virtuel, correspondent au 

systeme reel modelise. 

Avantageusement, I'analyse de la securite peut avoir lieu tres tot dans 

le processus de conception du systeme d'information, et notamment avant son 

deploiement physique. 
20 Le procede permet de modeliser un systeme d'information, en se 

limitant a ses aspects securite, et done en restant maitrisable par une personne 

humaine, grace a des concepts et principes simplificateurs. L'invention permet 

de traiter d'une fagon generique les aspects notamment techniques (e'est-a- 

dire lies aux caract6ristiques techniques du systeme d'information), humains, 
25 proceduraux et physiques (par exemple g6ographiques). Un bon compromis 

entre realisme et simplicite de la modelisation permet a un utilisateur 

(typiquement le concepteur ou Tadministrateur du systeme d'information, ou un 

auditeur technique de la securite) de modeliser le systeme d'information sans 

avoir a le reproduire completement. 
30 Le procede permet aussi de simuler avec realisme toutes les attaques 

connues dans le monde des systemes d'information. Ces attaques s'av6rent 

g6neriques, et peuvent s'appliquer aux domaines connexes des systdmes 

d'information (securite physique par exemple). 
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II permet enfin de simuler avec realisme toutes les parades connues 
dans le monde des systemes d'information, qu'elles soient de prevention ou de 
detection. La moderation des parades de prevention est realisee par des 
regies de s6curite. La moderation des parades de detection est realisee au 
5 moyen de metriques. 

En resume, le proced6 permet d'analyser en peu de temps la faisabilite 
d'un tres grand nombre d'attaques sur un systeme donne. Avec un peu 
d'exp^rience, Tutilisateur peut simuler environ 100 a 200 attaques etementaires 
par jour, ce qui est considerablement plus que ce qu'on pourrait faire sur un 
10 systeme reel. 

Un second aspect de I'invention conceme un dispositif pour la mise en 
oeuvre d'un procede selon le premier aspect. A cet effet, le dispositif comprend 
avantageusement une interface Homme / machine pour la mise en oeuvre de la 
phase de mod6lisation et/ou un moteur attaques / parades pour la mise en 
15 oeuvre de la phase de simulation 

Avantageusement, interface Homme / machine presente une 
fonctionnalite d'affichage en multi vues du systeme modelis6. 

De preference, Tinterface Homme / machine permet d'afficher le 
systeme modeiise selon un modele composants / relations. 
20 Le dispositif est destine a etre utilise en tant qu'outil d'audit technique 

de la security des systemes d'information existants (c'est-a-dire dej^ deployes), 
pour lesquels il presente Tavantage de ne pas les perturber pendant leur 
exploitation. II peut notamment analyser des attaques destructives sans 
affecter le systeme reel. 
25 Le dispositif peut aussi etre utilise en tant qu'outil d'aide a la conception 

de la security de systemes en cours de conception ou de realisation, ce qui 
permet la mise au point et le test de leur politique de protection avant meme 
leur installation. 

II peut aussi etre utilise en tant qu'outil privilegie de certification de 
30 systeme, au sens de la certification securite selon la normalisation existante: 
TCSEC, ITSEC ("Information Technology Security Evaluation Criteria") et CC 
("Common Criteria"). Cette normalisation permet en effet actuellement de 
certifier des produits aux contours nettement delimites, mais est jusqu'a 



WO 2004/046974 




CT/FR2003/003309 



4 



maintenant inapplicable aux systemes. Ces derniers sont en effet trap vastes, 

complexes, heterogenes, aux contours mal definis et evolutifs, pour etre 

evalues avec les techniques devaluation de produits. 

En resurn6, le dispositif est un outil destine a des specialistes de la 
5 s^curite: administrateurs systeme, auditeurs techniques de la security. A ces 

personnes, il apporte en plus la possibility d'adopter le point de vue de 

I'attaquant, point de vue absolument necessaire pour construire une protection 

efficace et adaptee. 

D'autres caracteristiques et avantages de Invention apparaTtront 
10 encore a la lecture de la description qui va suivre. Celle-ci est purement 

illustrative et doit etre lue en regard des dessins annexes sur lesquels : 

- la figure 1 est un diagramme illustrant les phases de moderation et 
de simulation selon le procede de invention ; 

- la figure 2 est un schema synoptique illustrant les elements d'un 
15 dispositif selon I'invention ; 

. -la figure 3 est un schema illustrant la construction d'un modele 
composants / relations pour un systeme d'information ; 

- la figure 4 est un schema montrant un exemple de modele 
composants / relations, sur lequel apparaissent des relations d'hebergement et 

20 des relations d'echange entre des composants ; 

- la figure 5 est un schema illustrant des exemples de relations de 
service entre des composants d'un systeme dlnformation modelis6 selon 
Tinvention ; 

- la figure 6 est un schema qui illustre un exemple detaill6 de la phase 
25 de simulation du procede selon I'invention 

- les figures 7a a 7e sont des schemas qui illustrent des exemples de 
chemins d'attaque ; 

- la figure 8 est un schema montrant la transmission d'une attaque a 
travers un chemin d'attaque dans un systeme d'information modelis6 ; 

30 - la figure 9 et la figure 10 sont des schemas presentant un mecanisme 

de piles amont et aval ; 

- la figure 1 1 est un schema illustrant un exemple de fonctionnement 
des piles amont et aval ; 
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- la figure 12 est un diagramme illustrant I'algorithme general de 
fonctionnement du moteur attaques / parades ; 

- la figure 13 est un diagramme qui illustre un mecanisme d'application 
des regies de protection ; 

5 - les figures 14a et 14b sont des diagrammes illustrant un mecanisme 

de routage fonctionnel et un mecanisme de contagion d'etats, respectivement ; 

- la figure 15 est un schema illustrant des techniques de detournement 
dans un systeme d'information modelise ; 

-la figure 16 est un schema illustrant I'affichage d'un systeme 
10 modelise, avec une fonctionnalite multi-vues ; 

-la figure 17 est schema illustrant I'affichage multi vues selon une 
approche hierarchique ; et, 

- la figure 18 est un schema synoptique d'un dispositif selon I'invention. 
Comme illustre par le graphe de la figure 1, le procede comporte deux 

1 5 phases d'utilisation, elles meme decomposees en deux etapes. 

Pendant une phase de modelisation, I'utilisateur adopte le point de vue 
du defenseur. La phase de modelisation comprend une etape 1 de 
specification de Parchitecture du systeme avec un ensemble de composants du 
systeme et des relations entre lesdits composants, qui comprennent des 

20 relations de propagation et des relations de service. L'etape 1 aboutit a 
I'architecture modelisee du systeme reel, appelee modele 
composants / relations dans la suite, ce modele etant sauvegarde sous la 
forme d'un fichier dans une memoire 1 1 . Ce modele peut etre represente de 
facon graphique par un graphe comportant des boltes symbolisant les 

25 composants, reliees par des fleches symbolisant les relations. La phase de 
modelisation comprend aussi une etape 2 de specification de regies de 
comportement, a ne pas confondre avec les relations precitees. Ces regies de 
comportement definissent le fonctionnement de chaque composant, aux plans 
du fonctionnement et de la securite, en particulier les protections qu'il assure. 

30 L'etape 2 aboutit a la construction d'un fichier de regies de comportement, qui 
est sauvegarde dans une memoire 12. 

A I'inverse, pendant une phase de simulation, Tutilisateur adopte le 
point de vue de I'attaquant. La phase de simulation comprend une etape 3 de 
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specification des attaques, qui aboutit a la creation d'un ou plusieurs scenarios 
d'attaques. Ces scenarios sont sauvegardes sous la forme de fichiers dans une 
memoire 13. La phase de simulation comprend aussi une etape 4 de simulation 
interactive d'attaques. Cette simulation est realisee par un moteur 

5 attaques / parades. Elle aboutit a la creation d'un journal des attaques, qui est 
sauvegarde sous la forme d'un fichier dans une memoire 14. 

Les fichiers sauvegardes dans les memoires 11, 12, 13 et 14 peuvent 
etre importes de ou exportes vers differentes applications, en sorte que leur 
reutilisation est possible. 

10 Les phases de modelisation 10 et de simulation 20 peuvent etre iterees 

de fagon alternee, en modifiant a chaque fois tout ou partie des parametres 
(modele composants / relations, regies de comportement, attaques) pris en 
compte. Ceci permet une bonne mattrise de la securite du systeme par 
I'utilisateur. 

15 Dans la suite de la description, il est decrit un mode de mise en oeuvre 

des etapes 1 a 4 du proc^de, avec toutefois une presentation mod ifiee quant a 
I'ordre des etapes. En effet, I'etape 3 (specification d'attaques) et I'etape 4 
(simulation interactive par moteur attaques / parades) sont exposees avant 
I'etape 2 (parametrage des regies de protection), pour aider a la 
20 comprehension du texte. En outre, la description de ces etapes est completee 
par une presentation de deux m6canismes complementaires : les m6triques et 
I'interface Homme / machine (IHM). 

Au prealable, les principaux elements d'un dispositif selon I'invention 
sont presentes en reference au diagramme fonctionnel de la figure 2. Sur cette 
25 figure, on a represents en partie haute un groupe 20a des elements utilises 
pendant la phase de modelisation, et en partie basse un groupe 20b de ceux 
utilises pendant la phase de simulation. De plus, une interface 
Homme / machine 15 est representee sur la droite. 

Le groupe 20a comprend un langage de regies 21 permettant 
30 d'elaborer les regies de protection 22, un ensemble de metriques de base 23, 
et le modele composants / relations 24. 

Le groupe 20b comprend un langage d'attaques 25 permettant 
d'elaborer les scenarios d'attaques 26, le moteur attaques / parades 16, un 
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mecanisme de piles amont et aval 27, un ensemble d'etats potentiels 28 et des 
metriques calculees 29. 

A la figure 2, les fleches en traits continus symbolisent les transferts 
d'informations entre les elements, et les traits discontinus symbolisent les liens 
5 fonctionnels entre les elements. Le r6le de chacun de ces elements apparattra 
dans ce qui suit. 

La premiere etape du procede, etape 1 , consiste a construire le modele 
composants / relations (ou architecture) du systeme reel via Interface humaine 
15. Pour cela, le systeme est decompose en composants elementaires (ou 
10 atomes), dotes d'attributs, et relies par des relations. 

Les etapes de la construction du modele composants / relations sont 
illustres par le graphe de la figure 3. 

line premiere etape 31 , Tutilisateur met en place sur un graphe a deux 
dimensions les composants qui torment le systeme. Dans un exemple, chaque 
15 composant est represents par un rectangle contenant ses quatre etats 
potentiels et son ndm. 

Les composants peuvent representer toutes sortes d'objets reels 
heterogenes de type physique (site, batiment, etage, local, bureaux coffre, 
porte, fenetre, serrure, cle,...), support (papier, disque fixe, disquette, CDROM, 
20 bande magnetique,...), reseau (electrique, informatique, t6lephonique, hertzien, 
aerien,...), materiel (mecanique, reseau, informatique, poste, serveur, ecran, 
clavier, imprimante,...), logiciel (OS, driver, application, service,...), donnees 
(repertoire, fichier, information, base de donnees, mot de passe,...), personnes 
(utilisateur, agresseur, directeur, administrates, organisation, service, ..,). etc. 
25 Cette liste indicative est non limitative. 

Chaque composant a plusieurs attributs, qui sont definis dans une 
etape 32. Les attributs comprennent des attributs statiques et des attributs 
dynamiques. Les attributs statiques comprennent par exemple un nom 
(compose d'une nature et d'un identifiant), et eventuellement un ou plusieurs 
30 adjectifs. Les attributs dynamiques comprennent par exemple des etats 
potentiels dits etats "ACID" (voir plus loin), un nom pretendu (dans le cas ou le 
composant est usurpateur), et un lien vers un composant usurpateur (dans le 
cas ou le composant est usurpe). 



WO 2004/046974 




CT/FR2003/003309 



8 



Les adjectifs ont pour but de permettre de designer des composants 
sans les nommer. et ceci soit dans des regies (par exemple: tous les 
composants "externes" sont interdits d'acces), soit dans des attaques (par 
exemple: decouvrir tous les composants "IP"). La liste des adjectifs est ouverte, 
5 et definie par I'utilisateur lors de la moderation. Un exemple d'adjectifs classes 
par utilite est donne par la tableau I ci-dessous : 



utilite 


adjectifs 


appartenance 


interne, externe, prive, public, etablissement, groupe, 
central, local, distant 


sensibilite, gravite 


normal, important, critique, vital, droits reserves (DR), 
confidentiel defense (CD), secret defense (SD), top- 
secret defense (TSD), tactique, strategique 


droit d'acces, role 
technique ou 
organisationnel, 
interne ou externe 


usager, r6dacteur, lecteur, editeur, technicien, op6rateur f 
exploitant, administrateur, stagiaire, employe, gardien, 
surveillant, respdnsable, gestionnaire, directeur, client, 
partenaire, consultant, fournisseur, client, concurrent 


confiance ou 
mefiance 


fiable, fidele, sincere, serieux, connu, inconnu, douteux, 
suspect, pirate 


technique 


IP, reseau, informatique, OS, executable, information, 
fixe, mobile. 


protection 


crypte, cache, secouru, repertorie, administr6, duplique 



Tableau I 



10 La moderation est une tache complexe pour Tutilisateur. C'est 

pourquoi les mecanismes de moderation sont congus pour fonctionner meme 
sur un modele non completement termine, done eventuellement partiellement 
incoherent. Ceci permet a Tutilisateur de travailler selon un processus 
progressif et iteratif, alternant la moderation et les tests de fonctionnement par 

15 simulation. 

Les composants sont ubiquistes et intemporels. Ce principe a pour but 
de simplifier le travail de moderation, sans nuire au realisme, dans la mesure 
ou le theme est la security. II se traduit concretement par le fait qu'un 
composant peut etre, notamment : 
20 - multiple, e'est-a-dire representer plusieurs objets reels semblables 

situes en plusieurs endroits ; 
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- disperse, c'est-a-dire representer un objet de grande taille non situe 
dans une zone precise (par exemple un reseau); 

- partiel, c'est-a-dire representer une partie d'un objet reel complexe ; 

- replique, lorsque deux composants peuvent representer le meme 
5 objet reel (par commodite de moderation) ; 

-duplique, lorsque, par exemple, un meme fichier reel presente 
plusieurs copies sur plusieurs supports ; 

- temporaire, c'est-a-dire representer par exemple une communication 
tel6phonique intermittente ; et 

10 -mobile: par exemple, un poste portable, ou une personne sont 

mobiles ("nomades") par nature. 

Dans une etape 33, ont definit des relations de propagation associees 
aux composants. Ces relations sont bidirectionnelles, et susceptibles de 
vehiculer des attaques dans les deux sens. Elles peuvent etre de deux types 

1 5 distincts : de type hebergement (contenance, alimentation) et de type echange. 

Le schema de la figure 4 illustre un exemple de relations 
d'hebergement (symbolisees par des fleches verticales) entre un logiciel client 
41, un poste de travail 42 (un ordinateur personnel ou PC) dans lequel ledit 
logiciel client est sauvegarde, et un bureau 43 dans lequel ledit poste de travail 

20 est situe. Le meme schema illustre aussi des relations d'6change entre le 
logiciel client 41 et un logiciel serveur 44 avec lequel le logiciel client echange 
des donnees, entre le poste de travail 42 et un reseau informatique auquel le 
poste de travail est raccorde 45, et entre le bureau 43 et un couloir 46 
permettant Faeces audit bureau. 

25 Quand un composant est traverse par une attaque, il peut ou non 

laisser une trace du passage dans Tattaque. Par exemple, un paquet postal 
porte le cachet du bureau de poste emetteur, mais pas du bureau de poste 
recepteur. De meme, un paquet IP ("Internet Protocol") contieht ou non 
I'adresse IP d'un routeur traverse. 

30 Pour prendre en compte cette reality, chaque composant, pour 

chacune des relations qull regoit, a un indicateur de transparence ou opacite. 
S'il est transparent, il ne sera pas vu des composants avals sur le chemin de 
Tattaque, et ces composants ne pourront done pas en tenir compte dans leurs 
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regies de protection. Si au contraire il est opaque, les composants avals le 
verront, mais il cachera les composants amonts de meme type (c'est a dire 
ayant les memes adjectifs). 

A cot6 des relations de propagation, on prSvoit aussi des relations de 
5 service, qui sont definies dans une etape 34. Les relations de service sont 
unidirectionnelles, et ne v6hiculent pas d'attaques. Elles ont pour but de 
permettre de designer un composant a partir d'un autre, sous la forme d'une 
indexation. 

Le schema de la figure 5 illustre un exemple de relation de service. Sur 

10 cette figure, on a represents un poste de travail 51, une personne 52, un mot 
de passe 53 et un bureau 54. Des relations de propagation entre ces 
composants sont symbolisSes par des traits continus, et des relations de 
service sont symbolisees par des traits discontinus le composant. Dans cet 
exemple, le composant "mot de passe" 53 peut etre designe par la formule 

15 ,, passe(personne)". De meme, le composant "bureau B24" peut etre dSsigne 
par "bureau(persorine)". 

De retour a la figure 3, on notera que les Stapes 31 a 34 peuvent etre 
iterees pour permettre a I'utilisateur d'affiner la construction du modele 
composants / relations. 

20 Quand le modele composants / relations est termine, une table de 

routage est construite dans une etape 35. Cette table est calculee 
automatiquement selon le principe du plus court chemin entre les composants, 
en utilisant les relations de propagation uniquement. Le resultat est par 
exemple une matrice composant de depart / composant d'arrivee. 

25 L'evolution dans le temps de chaque composant est memorisee au 

moyen de quatre etats potentiels, appeles etats "ACID" (A = activite, 
C = confidentiality, I = int6grite, D = disponibilite). Ces etats correspondent aux 
trois domaines connus de la securite (C, I, D), auxquels a ete ajoute I'etat "A" 
pour "activite". Ce dernier etat represente la capacity d'un composant a agir, 

30 soit de fagon normale (licite), soit de fagon malveillante, et ceci sous Tinfluence 
de Tagresseur. 
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On pourra noter que ces etats ACID correspondent sensiblement aux 
droits elementaires des modeles de securite: "XRWD" (X = execute, R = read, 
W = write, D = delete), lis sont independants les uns des autres. 

Dans un exemple chaque etat a quatre valeurs possibles : normal, 
5 affaibli, degrade, dangereux. Dans un exemple, ces valeurs sont codees sur le 
graphe composants / relations par un code de couleur (par exemple vert, 
jaune, rouge, bleu fonce, respectivement), utilis§ pour le remplissage du 
rectangle symbolisant chaque composant. 

Le tableau II ci-dessous donne la signification des quatre valeurs 
10 possibles des quatre etats ACID potentiels. 



Etats ACID : 


Activite 


Confident! a lite 


Integrite 


Disponibilite I 


sain 


ferme 


discret 


integre 


disponible 


affaibli 


ouvert 


decouvert 


usurpateur 


sature 


degrade 


actif 


divulgue 


altere 


bloque 


dangereux 


interactif 


trahi 


corrompu 


detruit 



Tableau II 



Le but de I'analyse est d'etudier la possibility de realiser une intrusion 
15 dans un systeme. Dans la mesure ou il est necessaire de faire des 
simplifications par rapport a la realite, il est preferable de simplifier dans le sens 
du pessimisme, ceci dans un but securitaire. En d'autres termes, le dispositif 
peut voir des intrusions la ou il n'y en n'a pas, mais ne doit pas oublier des 
intrusions reellement possibles. L'utilisateur fera ensuite la part des choses, si 
20 necessaire. 

Ce principe, dit de la "politique du pire" est applique dans le moteur 
attaques / parades de la maniere suivante. 

Au depart de la modelisation, les quatre etats potentiels de chaque 
composant sont respectivement initialises a la valeur "sain". L'utilisateur peut 
25 les initialiser manuellement a une valeur differente s'il le souhaite. Les etats ne 
peuvent ensuite evoluer que vers la degradation, au fur et a mesure des 
attaques reussies. 

Les etats sont "potentiels", c'est-a-dire qu'ils signifient que les 
composants "peuvent" se trouver dans les etats indiques, mais pas forcement. 
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Ceci implique que deux etats apparemment incompatibles (par exemple, un 
composant a la fois "actif" et "detruit") peuvent coexister. Quand deux etats 
sont incompatibles ou incoherents, le dispositif choisit la situation la plus 
defavorable au defenseur. 

5 Quand un composant (modelise) represente plusieurs objets reels, ses 

etats potentiels sont ceux de I'objet reel le plus degrade. 

Enfin, le test d'un etat de composant dans une regie ne correspond pas 
a une relation d'egalite, mais a une relation d'ordre. Par exemple, le test 
"composant = bloque" est positif si le composant est soit "bloque", soit "detruit". 

10 On va maintenant decrire un exemple de mise en oeuvre de I'etape 3 et 

de l'6tape 4 du procede, a savoir la specification des scenarios d'attaque et leur 
simulation interactive. A cet effet, il est fait reference au diagramme de la figure 

Dans une etape 61 , une attaque est definie. Dans un exemple, il est 
15 prevu une attaque pour chaque degradation d'un etat ACID. Les attaques 
correspondantes sont appelees attaques elementaires dans la suite. Elles sont 
liees directement aux etats ACID. Par exemple, pour faire passer un 
composant a I'etat "bloque", on utilise I'attaque "bloquer". 

II y a done douze attaques elementaires (correspondant aux douze 
20 valeurs d'etats potentiels non saines), qui sont resumees dans le tableau III ci- 
dessous, plus une attaque speciale dite attaque d'usurpation. Cette derniere 
attaque, appelee "ChangerNomPretendu", permet a un composant d'usurper le 
nom d'un autre. L'usurpation est en effet une technique fondamentale de 
I'intrusion. 

25 



attaques 
ACID 


Activite 


Confidentialite 


Integrite 


Disponibilite 


faible 


ouvrir 


decx>uvrir 


usurper 


saturer 


grave 


activer 


i espionner 


alterer 


bloquer 


Idangereuse 


penetrer 


I trahir 


corrompre 


detruire 



Tableau III 



Lore de la definition d'une attaque elementaire, Tutillsateur (qui se 
place du point de vue de rattaquant) saisit les parametres suivants : 
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- type d'attaque, parmi les 13 ci dessus ; 

- type de protocole (voir ci dessous) ; et, 

- elements du chemin (voir plus loin). 

Le "protocole" generalise le concept de protocole de 
5 telecommunication, et designe tout moyen de transmission d'une attaque entre 
deux composants. Une attaque se concretise toujours par la transmission dans 
le systeme d'un objet reel, physique ou logique, vehiculant des informations, 
des logiciels ou des mecanismes malveillants. 

La liste des protocoles est ouverte, I'utilisateur pouvant en definir 
10 autant qu'il souhaite lore de la moderation. Des exemples de protocoles sont : 

- protocoles physiques : lettre, colis, disquette, CDROM, personne,... 

- protocoles logiques et informatiques : mail, web, fichier, Telnet, 
Netbios, TCP/IP, FTP, SSL,... 

- protocoles specialises : missile, onde hertzienne, laser, ... 

15 -etc. 

Le langage d'attaque utilise les memes mots que le langage de regies, 
et permet de definir des scenarios d'attaques complexes. Une ligne d'attaque 
elementaire est par exemple : 

"depart=agresseur + intermediaire=lnternet + protocole=mail + arrivee=usager 
20 + attaque=detruire + cible=poste(usager)" 

En francais, cette ligne d'attaque signifie que I'agresseur envoie, via Internet, 

un courrier electronique a I'usager, contenant une bombe logique qui va 

detruire son poste. 

Le chemin d'attaque est Tun des concepts centraux du dispositif, dont 
25 I'objet est justernent de trouver des chemins d'attaque dans un systeme 

modelise. Lors de la simulation, I'utilisateur specifie le chemin sous la forme 

suivante : 

- un composant de depart ; 

- un composant d'arrivee ; 

30 - un composant cible ; et, eventuellement 

- un composant intermediaire. 

L'agresseur et la cible doivent necessairement se trouver sur le 
chemin, mais pas necessairement au debut ou a la fin. Le schema des figures 
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7a a 7e montrent diverses possibilites (non limitatives) de chemin d'attaque, qui 
peuvent correspondre chacune a un cas reel. Par exemple, lorsque la cible est 
un poste de travail : 

- a la figure 7a, I'agresseur sature le poste de travail par du trafic 
5 artificiel transmis via le reseau ; 

- a la figure 7b, I'agresseur envoie un virus par courrier electronique qui 
est execute par un usager "pigeon", ce qui altere le poste de travail ; 

- a la figure 7c, I'agresseur est un serveur pirate, et c'est un usager 
"pigeon" qui consulte une page web sur serveur pirate et recoit un applet Java 

1 0 pirate qui altere le poste ; 

- a la figure 7d, I'agresseur est aussi un serveur pirate et le poste de 
travail (rendu actif) ouvre une "reverse back door" vers le serveur pirate ; et, 

- a la figure 7e, I'agresseur est un reseau altere par lequel passe une 
session, devoilant ainsi des informations du poste de travail. 

15 Bien entendu, les exemples ci-dessus sont illustratifs et nullement 

limitatifs. 

De retour a la figure 6, I'attaque specifiee a I'etape 61 est lancee dans 
une etape 62. Dans une etape 63, elle est executee par le moteur 
d'attaques / parades. Et dans une derniere etape 64, le resultat de I'attaque est 
20 constate. Les etapes 61 a 64 sont iterees, etant executees pour chaque 
attaque du scenario d'attaques. 

Le resultat d'une attaque, si elle reussit, est de faire passer I'un des 
etats ACID du composant cible a une valeur degradee (non saine), voire a une 
valeur degradee plus grave si il etait deja a une valeur degradee. Par exemple 
25 dans le cas de I'attaque "bloquer" : 

-si le composant est moins degrade que "bloque" (par exemple, 
"sature"), alors il devient "bloque" ; 

- s'il est deja "bloque", alors il reste "bloque" ; et, 

- s'il est plus degrade que "bloque" (par exemple "detruit"), alors il ne 
30 change pas d'etat. 

On va maintenant decrire plus en details le fonctionnement du moteur 
d'attaques / parades. Typiquement, la transmission d'une attaque sur le chemin 
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d'attaque se fait selon trois phases successives, illustrees par le schema de la 
figure 8, a savoir : 

- une phase de propagation durant laquelle Pattaque traverse les 
composants vecteurs, qui peuvent ou non assurer un filtrage de securite via 

5 leurs regies de protection ; 

- une phase d^bsorption durant laquelle Pattaque peut ou non 
degrader la cible, selon ses defenses propres (regies de protection) ; et, 

- une phase de contagion durant laquelle la degradation de la cible 
peut se communiquer a d'autres composants sans qu'ils puissent se d6fendre 

10 (par exemple, Pexplosion d'un bureau entraine la destruction des equipements 
presents dans ce bureau). 

Quand une attaque arrive dans un composant, le moteur 
attaques / parades effectue pour lui un certain nombre de controles (regies), 
bases sur les etats de certains composants, et en particulier sur les 

1 5 composants situes en amont et en aval sur le chemin de Pattaque. Pour ces 
derniers, representes sur le schema de la figure 9, les informations dont 
dispose le moteur attaques / parades sont consignees respectivement dans la 
pile amont et dans la pile aval qui ont ete presentees plus haut en regard du 
schema de la figure 2. Ces piles amont et aval sont la mod6lisation des 

20 indications portees sur les objets reels (par exemple adresses et cachets de la 
Poste sur un colis, adresses IP sur un paquet IP, etc.). 

La pile amont donne la liste (dans Pordre) de tous les composants deja 
traverses par Pattaque. Dans un exemple, il y a precisement deux piles amont : 
Tune qui contient la liste exhaustive de tous les composants, avec leur nom 

25 reel, et Pautre qui. contient uniquement la liste des composants opaques, avec 
leur nom pretendu. La premidre liste est utilisee pour executer les regies de 
possibility et de contagion du composant. L'autre est utilisee pour executer 
pour les regies de protection (identification, autorisation et routage). 

La pile aval donne la liste des destinataires identifies de I'attaque. II y a 

30 un destinataire final, et eventuellement un ou plusieurs destinataires 
intermediaires. Ces destinataires intermediaires sont specifies, soit par 
Tutilisateur lors de la definition d'une attaque, soit par le routage fonctionnel. La 
pile aval est utilisee par les regies des composants. 
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Dans I'exemple illustre a la figure 10, le routeur 111 et I'internet 112 
sont transparents (car I'adresse IP source des paquets IP venant de I'exterieur 
est inchangee). C'est pourquoi, etant empiles dans la premiere pile amont 1 10 
des noms reels, et ils ne sont pas empiles dans la seconde pile amont 120 des 

5 noms visibles (c'est-a-dire reel ou pretendu, le cas echeant). Par ailleurs, le 
pirate 113 usurpe le nom d'un usager 114. Son "nom visible" (empile dans la 
seconde pile amont 120) est done "usager" et non "pirate". La pile aval est 
designee par la reference 130. 

Pour chaque transit d'une attaque, le moteur effectue les trois 

10 operations suivantes : 

- preincrement, il determine le prochain composant destinataire de 
I'attaque: c'est le premier composant de la pile aval, 

- deuxiemement, il determine, grace a la matrice de routage local, 
quelle est la relation a emprunter pour aller vers ce composant ; et, 

15 - troisiemement, le composant qui se trouve de I'autre cote de la 

relation devient le composant en cours. 

L'attaque s'arrete quand la pile aval est vide (et non quand le 

composant d'arrivee est atteint, car d'autres composants peuvent etre empiles 

en aval apres I'arrivee). 
20 Pour le composant en cours (atteint par l'attaque), le moteur effectue 

les operations suivantes, illustrees par le schema de la figure 11 : 

- il extrait le composant en cours de la pile aval, s'il y est (etape 1) ; 

- il teste les regies de propagation du composant, qui peuvent accepter 
ou refuser l'attaque ; 

25 - si l'attaque est refusee, le moteur I'arrete, sinon il continue les actions 

suivantes, 

- dans le cadre des regies de routage fonctionnel, il peut empiler un 
composant intermediaire en aval (etape 2) ; 

- il empile le composant en cours dans la pile amont (etape 3) ; et 
30 - si l'attaque est acceptee, il la route vers le composant suivant. 

L'algorithme general de fonctionnement du moteur d'attaques / parades 
est donnee par le diagramme de la figure 12. 
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Sur ce diagramme, le mot-cle "moi" designe le composant en cours. 
Pour transporter ou absorber une attaque, le composant en cours doit etre 
dans I'etat "ouvert" (etat A des etats ACID). Pour absorber I'attaque, le 
composant cible doit se trouver dans la premiere pile amont, celle des noms 
5 reels. On notera que les regies d'idenfrfication et d'autorisation donnent 
toujours "oui" pour resultat si le composant est corrompu. 

A la figure 12, les trois phases de la transmission de I'attaque, a savoir 
la propagation, I'absorption et la contagion de I'attaque, sont representees 
separement. 

10 On va maintenant decrire I'etape 2 du procede, qui est le parametrage 

des regies de protection des composants. 

Lorsque I'architecture d'un systeme est specifiee (a la fin de I'etape 1), 
cette architecture etant representee par le graphe composants / relations, il 
reste en effet a decrire le comportement des composants, aux plans du 

1 5 fonctionnement et de la securite. 

A cet effet, I'etape 2 consiste a parametrer le fonctionnement de 
chaque composant, et en particulier a decrire les protections qu'il assure. Ceci 
est fait au moyen de la saisie de regies, structures selon un langage et une 
grammaire de regies. 

20 Le langage de regies se caracterise par, sa capacite au realisme (pour 

decrire precisement le fonctionnement d'un composant reel), I'ergonomie pour 
I'usager (simplicite, souplesse, naturel, peu de signes speciaux) et la genericite 
(c'est-a-dire le fait de permettre une ^utilisation facile des regies d'un modele a 
I'autre). 

25 Au plan de I'editipn, le langage est de preference sous forme de texte 

ASCII ou XML, est lisible, modifiable et imprimable avec un traitement de texte 
classique (tel que Notepad, MS-Office), accepte des commentaires en langage 
naturel sous la forme: /* commentaire */, accepte les majuscules / minuscules 
et accents (mais qui ne sont pas discriminants), et utilise les caracteres "blanc" 

30 et Tigne suivante" uniquement pour la presentation. 

De preference, les mots du langage apparaissent de la meme facon et 
sous la meme forme dans la representation graphique du modele 
composants / relations, dans la specification des regies (langage de regies), 
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dans la specification des attaques (langage d'attaques), et dans le journal des 
attaques. 

Le langage est principalement un langage de predicats (ou criteres de 
condition logique), utilisant des operateurs logiques (tels que ET, OU, NON), 
5 des mots-cles (tels que "attaque", "amont", "aval", "protocole", "moi"), et des 
noms de composants sous forme directe ou par adjectif, ou encore par relation 
de service. 

Par exemple, le predicat "amont(person)=admin + attaque=corrompre" 
signifie que I'attaque "corrompre" est autoris^e a passer dans le composant s'il 
10 y a en amont une personne ayant r6le "admin" (administrates). 

Un exemple de mots-cles generiques, qui est illustratif seulement, est 
donne par le tableau IV ci-dessous. Par ailleurs, a ces mots cles generiques, il 
y a lieu d'ajouter les seize valeurs des etats potentiels et les douze valeurs des 
attaques. 
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mot-cle 
genenque 


designe 


signification 


utilisable par 




regies < 


attaques 


amont 


composant 


en amont (regies possiumie ei 


+ 




a mom 


UUiIipUocil ll 


pn amnnt fautrps reoles^ SOUS nom 
pretendu 


* 




I aval 


comDosant 


en aval 


+ 




mni 


comoosant 


en cours de traitement 






tJI HI cc 


nomnosant 


dernier traverse en amont (= 
relation d'entree) 


+ 




H£n?irt 


comoosant 


premier en amont 


+ 


+ 


cible 


composant 


cible de I'attaque 


T 


T 


arrivee 


composani 




J. 
i 


4. 
1 


attaque 


anaque 




+ 


: 1 


protocole 


protocole 


type de protocole 


+ 


— H 


intermediate 


composant 


impose sur le chemin ae i attaque 








mode 


indiaue si I'attaaue est licite ou non 




+ 


present 


etat 


presence d'un composant dans 
une pile 


+ 




absent 


etat 


absence d'un composant dans une 
pile 


+ 




authentique 


etat 


etat d'un composant non usurpe 


+ 




usurpe 


etat 


etat d'un composant usurpe par un 
autre 


+ 




usurpateur 


composani 


composant qui en usurpe un autre 


+ 





Tableau IV 



Le langage de description des composants permet d'ecrire des regies, 
5 qui component chacune un nombre variable de predicats (condition logique 
bdoleenne) et eventuellement d'actions. Pour chaque composant, il existe huit 
types de regies. Les regies ont deux caracteristiques independantes : 

- elles peuvent etre binaires (condition logique booleenne, donnant une 
valeur oui / non) ou fonctionnelles (condition logique impliquant une action de 

1 0 routage ou de contagion) ; et, 

- elles peuvent etre "de propagation" (dans les composants vecteurs 
des attaques) ou "d'absorption" (dans les composants cibles des attaques). 
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Dans un exemple, cinq regies de propagation et trois regies 
cTabsorption sont donnees respectivement par le tableau V et par le tableau VI 
ci-dessous. 



regie 


type 


role 


exemple 


possibility 


binaire 


definit quelles attaques 
peuvent passer 


un logiciel ne peut pas 
transporter un colis postal 


identification 
amont 


binaire 


assure ('identification et 
Tauthentification des 
composants amonts 


une attaque sera acceptee 
si le mot de passe a et6 
prealablement divulgu§ 


identification 
aval 


binaire 


assure 1'identification et 
Pauthentification des 
composants avals 




autorisation 


binaire 


definit quelles attaques 
sont autorisees a 
passer 


un dispositif pare-feu 
("firewall") peut interdire 
les attaques de decouverte 
par paquets "Ping" 


routage 


fonctionnelle 


definit vers quel 
composant diriger les 
attaques 


un routeur envoie les 
messages mail vers le 
serveur mail 



5 Tableau V 



{regie 


type 


role 


exemple 


possibility 


binaire 


definit quelles attaques 
peuvent passer 


un bureau peut absorber 
une bombe physique, mais 
pas une bombe logique 


identification 
amont 


binaire 


assure identification et 
Pauthentification 
eventuelle des 
composants amont 


une attaque sera acceptee 
si le mot de passe a 6te 
prealablement divulgue 


contagion 


fonctionnelle 


definit quels etats 
doivent etre propages 
vers quels composants 


Texplosion d'un bureau 
entraine la destruction des 
equipements heberges j 



Tableau VI 



Les regies sont appliquees de la fatjon suivante. Chaque fois qu'une 
10 attaque se pr6sente devant un composant (en cours), le moteur 
attaques / parades deroule le mecanisme illustre par le diagramme de la figure 
13. 
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Pour qu'une attaque soit propagee par un composant vecteur ou soit 
absorbee par un composant cible, chaque categorie de regie binaire doit, soit 
etre vide, soit comporter une regie avec resultat positif. 

Si I'attaque est acceptee par un composant vecteur, celui ci applique 
5 les regies de routage fonctionnel selon le mecanisme illustre par le diagramme 
de la figure 14a. De meme, si I'attaque est acceptee par le composant cible, 
celui ci applique les regies de contagion selon le mecanisme illustre par le 
diagramme de la figure 14b. 

On va maintenant decrire les mecanismes de routage local et 
10 fonctionnel. Le routage a pour fonction de dinger les attaques d'un composant 
a I'autre, dans le but d'atteindre le point d'arrivee ou les points intermediates. II 
existe deux sortes de routages. 

Premierement, le routage fonctionnel, defini par I'utilisateur via les 
regies de routage, et qui permet de definir un nouveau composant 
1 5 intermediate avant d'atteindre le point d'arrivee. Ce composant est insere dans 
la pile aval. Par exemple, un routeur decide de router un courrier electronique 
venant de I'exterieur vers le serveur de messagerie. 

Deuxiemement, le routage local, invisible de I'utilisateur, qui a pour 
effet de dinger I'attaque vers le prochain composant de la pile aval, selon le 
20 chemin le plus court. La table de routage local est utilisee a cet effet. On 
rappelle que cette table est construite automatiquement en fin de modelisation, 
selon le principe de recherche du plus court chemin. Dans un exemple, elle est 
structuree sous forme de matrice (composant de) depart / arrivee. 

Le routage fonctionnel permet d'assurer a la fois le fonctionnement 
25 nominal du systeme, et certaines fonctions de securite. Par exemple, un 
routeur qui envoi les paquets IP vers un dispositif pare-feu ("firewall") assure 
une fonction de securite. Cette fonction de securite peut etre degradee dans le 
cas du d6tournement, ainsi qu'il va maintenant etre decrit. 

La technique de detournement, fondamentale dans les scenarios 
30 d'attaque, peut etre prise en compte par le dispositif. Cette technique consiste 
a modifier la facon dont est fait le routage fonctionnel. II existe trois sortes de 
detournements, illustrees par le diagramme de la figure 15. 
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A ia figure 1 5 on a represents un exemple de chemin de propagation 
allant d'un client 151 a un serveur 155 a travers (dans cet ordre) un premier 
routeur 152, un filtre 153 et un second routeur 154. 

Un premier detournement est un dStournement par contoumement, 
5 symbolise par la fleche 156. Dans I'exemple represents, le routeur 152 est 
altSrS en sorte que son composant aval, le filtre 153, est supprimS. 

Un deuxieme detournement est un detournement par interception, 
symbolise par les fleche 158a et 158b. Dans I'exemple represents, le routeur 
152 est altere en sorte qu'un composant aval 157 est ajoutS sur le chemin de 
10 propagation. Ce composant aval est un pirate (usurpant). Dans ce cas, le 
serveur 1 55 est dit usurpe. 

Un troisieme detournement est un detournement par usurpation, 
symbolise par la fISche 150. Dans I'exemple represents, le routeur 154 est 
altere en sorte que son composant aval, le serveur 155, est remplacS par un 
15 autre composant aval 159. Cet autre composant aval est un pirate (usurpant), 
le serveur 1 55 est dit usurpe. 

Un detournement peut etre realise par tout composant ayant une 
fonction de routage, situe dans le chemin de I'attaque. II est dSclenchS par la 
reunion de trois conditions : 
20 - le composant de routage a un Stat "altere" (indiquant que ses tables 

de routage sont altSrSes) ; 

- le composant d'arrivee est "usurpe" (du moins pour I'usurpation et 
I'interception) ; et, 

- le composant de routage a une (ou plusieurs) regie particuliere qui 
25 prevoit le detournement. 

On va maintenant presenter un premier mecanisme supplemental de 
Pinvention, constituS par les mStriques de faisabilitS et de non detection. 

Les mStriques ont pour but de completer le langage de regies, qui est 
principalement axe sur la protection par prevention. Elles permettent de 
30 relativiser le succes ou Pechec des attaques, en calculant un coefficient de 
faisabilite et de non detection, apportant ainsi la protection par detection. 
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Dans un exemple, il existe cinq metriques dont trois metriques de base, 
qui sont parametrees lors de la modelisation, et deux metriques de probabilite 
de sinistre, qui sont calculees lors de la simulation. 

Pour eviter de tomber dans le travers de la complexity, les metriques 
5 de base sont evaluees sur un nombre restraint de niveaux, par exemple quatre 
niveaux. Cette echelle de niveaux doit etre comprise comme une echelle 
logarithmique, c'est a dire que chaque niveau implique un coefficient 
multiplicateur par rapport au niveau inferieur. Les quatre niveaux 
correspondent par exemple aux valeurs 0.1%, 1%, 10%, 100%. 
1 o Deux metriques de base relevent du point de vue du defenseur. II s'agit 

d'une metrique d'efficacite des parades (resistance), et d'une metrique 
d'efficacite de detection des attaques. Ces 2 metriques sont parametrees par 
I'utilisateur pendant la phase de modelisation, independamment pour chaque 
regie de protection dans chaque composant, selon une echelle de valeurs telle 
1 5 que faible, moyen, fort, absblu. 

. En outre, une metrique de base releve du point de vue de I'attaquant. II 
s'agit d'une metrique de moyens de I'attaquant. Cette metrique comprend par 
exemple les aspects suivants: competence, outils, argent, temps. Elle est 
parametree par I'utilisateur pendant la phase de simulation, de facon globale 
20 pour I'attaquant, tous moyens, toutes attaques et toutes cibles confondus. 
L'echelle de valeurs est par exemple : public, initie, sp6cialiste, expert. 

Les metriques de probabilite de sinistre sont calculees par le moteur 
attaques / parades lors du passage dans chaque composant, puis consolidees 
par le moteur sur tout le chemin, puis sur tout le scenario. II s'agit d'une 
25 metrique de probabilite de passage d'une attaque sur un composant, d'une 
part, et d'une metrique de probabilite de non detection d'une attaque sur un 
composant, d'autre part. De preference, elles sont exprimees sur l'echelle a 
quatre niveaux des metriques de base, a laquelle on ajoute le niveau 0%, et 
elles sont calculees selon les formule suivantes : 
30 - probabilite de passage = (moyens de I'attaquant) / (efficacite de la 

protection) ; 

- probabilite de non detection = (moyens de I'attaquant) / (efficacite de 
la d6tection). 
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Le tableau VII ci-dessous donne le calcul des metriques calculees. 



efficacite 
du 

defenseur 


0.1% 


faible 


0.1% 


1.0% 


10.0% 


100.0% 


1.0% 


moyen 


0.0% 


0.1% 


1.0% 


10.0% 


10.0% 


fort 


0.0% 


0.0% 


0.1% 


1.0% 


100.0% 


absolu 


0.0% 


0.0% 


0.0% 


0.1% 


| moyens de Pattaquant «=> 


public 
0.1% 


initie 
1.0% 


specialiste 
10.0% 


expert 
100.0% 



Tableau VII 



5 On va maintenant decrire un autre mecanisme suppl6mentaire de 

rinvention, qui fait partie de I'interface Homme / machine. 

Avantageusement, I'interface Homme / machine presente une 
fonctionnalite dite "multi vues". Ceci n'est pas en soi une originality, car la 
plupart des logiciels utilisent ce genre de fonctionnalite. Ce qui est original, par 
10 contre, c'est I'utilisation des vues pour aider I'utilisateur a maftriser des 
systemes complexes, grace a une association entre les vues (logicielles) et les 
sous-systemes (conceptuels). 

Le systeme des "vues" est un element important de I'interface 
Homme / machine, qui permet la modelisation de systemes complexes. Son 
1 5 principe est de decomposer le systeme en plusieurs vues, dont une seule est 
affichee a I'ecran dans la fenetre prindpale, I'utilisateur pouvant passer 
alternativement d'une vue a i'autre. Tout composant peut etre place dans une 
vue, dans une autre, ou dans plusieurs vues, au choix de I'utilisateur. 

Le schema de la figure 16 montre un exemple de representation 
20 graphique d'un systeme (modelise) selon trois vues superposees. Le serpentin 
symbolise un chemin d'attaque passant par les trois vues. 

II n'y a pas de contraintes pour la definition des vues, et pour la 
repartition des composants dans les differentes vues d'un systeme. On peut 
par exemple mettre en place des vues assoctees aux differents metiers du 
25 systeme (geographique, informatique, organisationnel). 

Avantageusement, moyennant certains principes simples, pris 
isolement ou en combinaison, les vues deviennent cependant un element de 
structuration fonctionnelle des systemes. 
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Selon un premier tel principe, chaque vue represente de preference un 
sous-systeme relativement autonome et independant du reste du systeme. 

Selon un deuxieme tel principe, on fait en sorte, de preference, qu'il 
n'existe pas de relations de propagation ni de services entre deux vues. Seuls 
5 les composants communs a deux vues assurent la fonction d'interconnexion 
entre les vues. 

Selon un troisieme tel principe, enfin, les regies des composants situes 
dans une vue ne doivent pas faire appel nommement a des composants situes 
dans une autre vue. 

10 Plus generalement, il y a deux faoons de concevoir les vues. Soit les 

vues sont considerees comme des sous-systemes de meme niveau 
interconnects entre eux (par exemple, des sites interconnectes via Internet, le 
composant commun etant Internet). Ou bien I'une des vues est consideree 
comme une description globale du systeme, tandis que les autres represented 

1 5 des details de tel ou tel composant complexe. Cette approche est appelee 
approche hierarchique et va etre detaillee maintenant. 

L'approche hierarchique est tres puissante, car eile permet d'assembler 
des composants detailles et mis au point prealablement pour former par 
assemblage des systemes tres complexes et realistes, tout en restant simple a 

20 visualiser. 

Dans cette approche, illustree sous la forme d'un exemple donne a la 
figure 17, une vue superieure presente le systeme global, qui contient un ou 
plusieurs composants representant chacun un sous-systeme. Chaque vue 
inferieure donne le detail d'un sous systeme. A la figure, le serpentin symbolise 
25 un chemin d'attaque passant par les deux vues. 

Un composant A commun a la vue superieure et a une vue inferieure, 
appele "composant relais", represente le sous systeme vu du systeme global, 
et reciproquement. Le composant relais est I'unique interface entre les deux 
vues. 

30 Le composant relais assure I'etancheite entre les vues, tout en 

assurant la communication entre elles, selon un triple role. 

Le composant relais assure tout d'abord un r6le de relais de routage. 
En effet, il assure le routage des attaques dans les deux sens entre les deux 
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vues. II utilise pour cela tous les criteres de routage disponibles dans le 
langage de regies. 

Le composant relais assure ensuite un role de relais de service. En 
effet, il peut avoir des relations de service, partant ou aboutissant, dans les 
5 deux vues. Ceci permet de designer un composant d'une vue a I'autre via 
Tindexation. 

Le composant relais assure enfin un role de relais de contagion d'etat. 
A cet effet, il assure pour la vue superieure une vision synthetique de la vue 
inferieure, via une contagion des principaux etats representatifs de cette vue. 
10 A la figure 18, sur laquelle les memes elements qu'aux figures 1 et 2 

portent les memes references, on a represents le schema synoptique d'un 
exemple de realisation d'un dispositif selon I'invention. Ce dispositif convieht 
pour la mise en ceuvre du procede selon I'invention. 

Dans cet exemple. le dispositif est implemente dans un ordinateur a 
15 usage general comprenant un microprocesseur 10. L'interface 
Homme / machine 15 et le moteur attaques / parades 16 sont mis en ceuvre 
sous la forme de modules logiciels, sauvegardes dans une memoire 17 et plus 
particulierement dans une memoire a lecture seule (ROM). Ms sont executes 
par le microprocesseur 10 lorsqu'ils sont charges dans la memoire vive de 
20 I'ordinateur. 

Pour assurer "I'entree de donnees par I'utilisateur, le dispositif 
comprend un clavier 19b, et en general egalement une souris (non 
representee) ou similaire. Pour I'affichage des donnees, notamment pour 
I'affichage de la representation graphique du systeme modelises sous la forme 
25 d'une on plusieurs vues, le dispositif comprend aussi un ecran. Ces elements 
sont ceux qui equipent I'ordinateur. 

Enfin, le dispositif comprend une memoire vive 18, en particulier une 
memoire a acces aleatoire (RAM), dans laquelle les fichiers 11, 12, 13 et 14 
peuvent etre sauvegardes. 
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REVINDICATIONS 

1 . Procede d'analyse de la securite d'un systeme d'information 
comprenant : 

-une phase de moderation (1,2), comprenant la moderation du 
systeme d'information, 
5 - une phase de simulation, comprenant la specification (3) et la 

simulation (4) d'attaques potentielles contre le systeme d'information. 

2. Precede selon la revendication 1 , suivant lequel la phase de 
moderation comprend la specification (1) de I'architecture du systeme avec un 
ensemble de composants du systeme et des relations entre lesdits 

10 composants. 

3. Procede selon la revendication 2, suivant lequel, un nom etant 
assocte a chaque composant, un ou plusieurs adjectifs peuvent aussi etre 
associes audit composant, lesquels adjectifs permettent de designer ledit 
composant sans le nommer. 

1 5 4. Procede selon la revendication 2 ou la revendication 3, suivant 

lequel des etats determines sont associes a chaque composant du systeme 
d'information, chaque etat pouvant prendre une valeur saine et une ou 
plusieurs valeurs non saines. 



20 desdits etats se rapportent respectivement a I'activite, a la confidentialite, a 
I'integrite et/ou a la disponibilite du composant auquel ils sont associes. 

6. Procede selon I'une quelconque des revendications 2 a 5, suivant 
lequel un nom pr6tendu peut etre associe a un composant determine 
quelconque, notamment dans le cas ou ledit composant determine est 

25 usurpateur. 

7. Procede selon I'une quelconque des revendications 2 a 6, suivant 
lequel un lien vers un autre composant peut etre associe a un composant 
determine quelconque, notamment dans le cas ou ledit composant determine 
est usurpe et ou ledit autre composant est usurpateur. 



5. Procede selon la revendication 4, suivant lequel certains au moins 
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8. Procede selon Tune quelconque des revendications 2 a 7, suivant 
lequel les relations entre deux composants determines quelconques, 
comprennent des relations de propagation bidirectionnelles susceptibles de 
vehiculer des attaques dans les deux sens. 

5 9. Procede selon I'une quelconque des revendications 2 a 8, suivant 

lequel les relations entre deux composants determines quelconques, 
comprennent des relations de service permettant de designer un composant a 
partir d'un autre composant. 

10. Procede seldn la revendication 2, suivant lequel la phase de 
10 moderation comprend en outre la specification (2) d'un ensemble de regies de 

comportement associees aux composants du systeme. 

11. Procede selon la revendication 10, suivant lequel chaque regie de 
comportement comprend un ou plusieurs predicats, et/ou une ou plusieurs 
actions. 

15 12. Procede selon la revendication 10 ou la revendication 11, suivant 

lequel les regies de comportement comprennent des regies de propagation 
d'attaques, ces regies etant par exemple mises en oeuvre dans des 
composants qui sont des vecteurs d'attaques, et des regies d'absorption 
d'attaques, ces regies etant par exemple mise en oeuvre dans des composants 

20 qui sont la cible d'attaques. 

13. Procede selon I'une quelconque des revendications 10 a 12, 
suivant lequel les regies de comportement comprennent des regies binaires, 
par exemple des conditions logiques booleennes donnant une valeur de type 
oui / non, et/ou des regies fonctionnelles, par exemple des conditions logiques 

25 impliquant une action de routage (pour une regie de propagation) ou de 
contagion (pour une regie d'absorption). 

14. Procede selon I'une quelconque des revendications 2 a 13 
comprenant, a la fin de la phase de moderation (figure 3), la construction (35) 
d'une table de routage local, permettant de dinger une attaque d'un composant 

30 de depart vers un composant d'arrivee. 
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15. Prbced6 selon la revendication 14, suivant lequel la table de 
routage local est g6n6r6e de fagon automatique suivant le principe du plus 
court chemin entre le composant de depart et le composant d'arriv6e. 

16. Proc6d6 selon Tune quelconque des revendications 3 & 15, suivant 
lequel I'etape de simulation des attaques comprend la mise a jour de P6tat d'un 
composant du systeme alt6r6 par une attaque r6ussie. 

17. Proc6d6 selon la revendication 16, suivant lequel la phase de 
simulation comprend en outre la constitution d'un fichier ou journal des 
attaques, contenant I'historique des changements de l'6tat des composants 
cons6cutifs d des attaques r6ussies, notamment pour permettre un traitement 
ulterieur par un utilisateur. 

18. Proc6d6 selon Tune quelconque des revendications pr6c&ientes, 
suivant lequel les attaques comprennent des attaques 6l6mentaires 
correspondant d des valeurs d'6tats non saines. 

19. Proc6d6 selon Tune quelconque des revendications pr6cedentes, 
suivant lequel les attaques comprennent en outre une attaque sp6ciale 
d'usurpation. 

20. Proc6d6 selon Tune quelconque des revendications pr6cedentes, 
suivant lequel une attaque est d6finie, notamment, par un type d'attaque, un 
type de protocole, et des 6l6ments de cbemin d'attaque. 

21 . Proc6d6 selon la revendication 20, suivant lequel les 6l6ments de 
chemin d'attaque comprennent un composant de depart, un composant 
d'arriv6e, un composant cible, et le cas 6ch6ant un ou plusieurs composants 
interm6diaires. 

22. Proc6d§ selon la revendication 20 ou la revendication 21, suivant 
lequel la liste des composants d6ja traverses par une attaque est sauvegardee 
dans au moins une ou plusieurs piles amont. 

23. Proc6d6 selon la revendication 22, suivant lequel les piles amont 
comprennent une pile (110) contenant la liste exhaustive de tous les 
composants travers6s, d6sign6s par leur nom r6el. 
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24. Procede selon la revendication 22 ou la revendication 23, suivant 
lequel les piles amont comprennent une pile (120) contenant la liste des seuls 
composants traverses qui sont opaques, designes par leur nom r6el ou, le cas 
6cheant, par leur nom pretendu. 

5 25. Procede selon Tune quelconque des revendications 20 a 24, 

suivant lequel la liste des composants destinataires d'une attaque est 
sauvegardee dans au moins une pile aval (130). 

26. Procede selon Tune quelconque des revendications 10 a 25, 
suivant lequel les attaques sont definies dans un langage utilisant les memes 

10 mots qu'un langage dans lequel les regies de comportement sont d6finies. 

27. Proc£d6 selon Tune quelconque des revendications precedentes, 
suivant lequel la phase de moderation et/ou la phase de simulation sont 
mises en oeuvre par un utilisateur au moyen d'une interface Homme/machine 
comportant une fonctionnalite multi vues, suivant laquelle une representation 

15 graphique du systeme est presentee a Putilisateur en plusieurs vues. 

28. Procede selon la revendication 27, suivant lequel chaque vue 
represente un sous-systeme du systeme, qui est relativement autonome et 
independant du reste du systeme. 

29. Procede selon la revendication 27 ou la revendication 28, suivant 
20 lequel la fonction d'interconnexion entre les composants compris dans deux 

vues distinctes est assuree seulement via le composant commun ou les 
composants communs aux deux vues. 

30. Proced§ selon I'une quelconque des revendications 27 a 29, 
suivant lequel les regies de comportement des composants appartenant a une 

25 vue ne font pas appel nommement a des composants appartenant a une autre 
vue. 

31 Procede selon Tune quelconque des revendications 27 a 30, suivant 
lequel les vues sont associees a des sous-systemes respectifs, par exemple de 
meme niveau, qui sont interconnects entre eux via au moins un composant 
30 commun. 
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32. Procecte selon Tune quelconque des revendications 27 a 30, 
suivant lequel une vue sup6rieure est assoctee au systeme dans son 
ensemble, tandis qu'une ou plusieurs vues inferieures sont respectivement 
associees & un sous-systeme d6termin6 du systeme. 

5 33. Precede selon la revendication 32, suivant lequel un composant 

d6termin§, commun a la vue supSrieure et d une vue interieure determin6e, 
repr6sente le sous systeme correspondant vu du systeme dans son ensemble, 
et reciproquement. 

34. Proced6 selon la revendication 33, suivant lequel ledit composant 
10 commun est I'unique interface entre les la vue superieure et ladite vue 

interieure d6termin6e. 

35. Procede selon Tune quelconque des revendications prec6dentes, 
suivant lequel la phase de mod6lisation comprend en outre la specification 
d'une ou plusieurs rrtetriques de base respectivement assoctees aux 

1 5 composants. 

36. Proc6d6 selon la revendication 35, suivant lequel les nrtetriques de 
base comprennent, une nrtetrique d'efficacite des parades, une m6trique 
d'efficacite de d6tection des attaques, et/ou une m6trique des moyens d'un 
attaquant. 

20 37. Proc6d6 selon Tune quelconque des revendications precedentes, 

suivant lequel la phase de simulation comprend le calcul d'une ou plusieurs 
metriques de probability de sinistre. 

38. Proced§ selon la revendication 37, suivant lequel les m6triques de 
probability de sinistre comprennent une metrique de probabilite de passage 

25 d'une attaque sur un composant. 

39. Proc6d6 selon les revendications 36 et 38, suivant lequel la 
ntetrique de probabilite de passage d'une attaque sur un composant est 
calcul6e suivant la formule " probabilite de passage = (moyens de 
I'attaquant) / (efficacite de la protection)". 

30 40. Proc6de selon la revendication 37, suivant lequel les nrtetriques de 

probabilite de sinistre comprennent une rrtetrique de probabilite de non 
detection d'une attaque sur un composant. 
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41 . Procede selon les revendications 36 et 40, suivant lequel la 
metrique de probability de non detection d'une attaque sur un composant est 
calculee suivant la formule "probabilite de non detection = (moyens de 
I'attaquant) / (efficacite de la detection)". 
5 42. Dispositif pour la mise en oeuvre d'un proced6 selon Tune 

quelconque des revendications precedentes, comprenant une interface 
Homme / machine (15) pour la mise en oeuvre de la phase de modelisation 
et/ou un moteur attaques / parades (16) pour la mise en oeuvre de la phase de 
simulation 

10 43. Dispositif selon la revendication 42, dans lequel Tinterface 

Homme / machine presente une fonctionnalite d'affichage en multi vues du 
systeme mod6lise. 

44. Dispositif selon la revendication 42 ou la revendication 43, dans 
lequel Tinterface Homme / machine permet d'afficher le systeme modelise 

1 5 selon un modele composants / relations. 
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